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Description 

REPAIRING ERRORS IN DATA OF MBMS SERVICE 

Technical Field 

[1] The present invention relates to providing wireless (radio) point-to-nultipoint 

services, such as multimedia broadcast and multicast service (MBMS), in UMTS 
(Universal Mobile Telecommunications System), which is a European type IMT-2000 
system and in particular, to receiving error-free raio MBMS service by a terminal by 
having the UTRAN re-transmit any portions of data that was received with errors by 
the terminal. 

Background Art 

[2] A universal mobile telecommunication system (UMTS) is a third generation 

mobile communications system that has evolved from the European Global System for 
Mobile communications (GSM) that aims to provide an improved mobile commu- 
nications service based upon a GSM core network and wideband code division 
multiple access (W -CDMA) wireless connection technology. 

[3] Egure 1 illustrates an exemplary basic structure of a UMTS network. As shown in 

Egure 1, the UMTS is roughly divided into a terminal 100 (or user equipment: UE), a 
UTRAN 120, and a core network (CN) 130. The UTRAN 120 includes one or more 
radio network sub-systems (RNS) 125. Each RNS 125 includes a raio network 
controller (RNC) 123, and a plurality of Node-Bs (base stations) 121 managed by the 
RNC 123. The RNC 123 handles the assigning and managing of raio resources, and 
operates as an access point with respect to the core network 130. The Node-Bs 121 
receive information sent by the physical layer of the terminal 100 through an uplink, 
and transmit data to the terminal through a downlink. The Node-Bs 121, thus, operate 
as access points of the UTRAN 120 for the tenrinal 100. Also, the RNC 123 allocates 
and manages radio resources and operates as an access point with the core network 
130. 

[4] The service provided to a particular tenrinal 100 is divided into circuit switched 

(circuit exchanged) service and packet switched (packet exchanged!) service. R>r 
example, typical voice telephone service falls under circuit switched (CS) service, 
while web-browsing service via an Internet connection is classified as packet switched 
(PS) service. To support circuit switched service, the RNC 123 connects with the MSC 
131 of the core network 130, and the MSC 131 connects with the GMSC 133 that 
manages connections coning from or going out to other networks. R>r packet switched 



WO 2005/067194 



2 



PCT/KR2005/000062 



service, the SGSN 135 and the GGSN 137 of the core network 130 provide appropriate 
services. Ibr example, the SGSN 135 supports the packet communication going to the 
RNC 123, and the GGSN 137 manages the connection to other packet switched 
networks, such as an Internet network. 
[5] Between various network structure elements, there exists an interface that allows 

data to be exchanged for communication therebetween. The interface between the 
RNC 123 and the core network 130 is defined as the Iu interface. The Iu interface is 
referred to as Tu-PS 1 if connected with the packet switched domain, and referred to as 
'Iu-CS 1 if connected with the circuit switched domain. Also, the interface between 
RNCs is referred to as ! Iur' and the interface between an RNC 123 and a Node B 121 is 
referred to as Tub'. 

[6] Hgure 2 illustrates a radio interface protocol architecture (structure) between the 

terminal 100 and UTRAN 110 that is based upon 3GPP wireless access network 
technology. Here, the radio access interface protocol has horizontal layers induing a 
physical layer, a data link layer and a network layer, and has vertical planes inducing 
a user plane for transmitting data information and a control plane for transmitting 
control signals. The user plane is a region to which traffic information of a user, such 
as voice data or Internet-protocol (IP) packets are transmitted. The control plane is a 
region to which control information, such as an interface of a network or maintenance 
and management of a call, is transmitted. In Hgure 2, protocol layers can be divided 
into a first layer (LI), a second layer (L2) and a third layer (L3) based upon the three 
lower layers of an open system interconnection (OSI) standard mcdel that is well- 
known in the art of wireless (mobile) communication systems. 

[7] Each layer shown in Hgure 2 will now be described. The first layer (LI) uses 

various radio transmission techniques to provide information transfer service to the 
upper layers. The first layer (LI) is connected via a transport channel to a medium 
access control (MAC) layer located at a higher level, and the data between the MAC 
layer and the physical layer is transferred via this transfer channel. 

[8] The MAC layer handles the mapping between the logical channels and the 

transport channels, and provides a re-allocation service of the MAC parameter for 
allocation and re-allocation of ratio (wireless) resources. The MAC layer is connected 
to an upper layer called a radio link control (RLC) layer through a logical channel, and 
various logical channels are provided according to the type of transmitted information. 
In general, when information of the control plane is transnitted, a control channel is 
used. When information of the user plane is transnitted, a traffic channel is used. Also, 
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the logical channels include a common channel and a dedicated channel depending on 
whether the logical channel is shared. The logical channels include a dedicated traffic 
channel (DTCH), a dedicated control channel (DCCH), a common traffic channel 
(CTCH), a common control channel (CCCH), a broadcast control channel (BCCH) 
that provides information induing information usable for the terninal to access a 
system and a paging control channel (PCCH) used by the UTRAN to access a 
terninal. 

The MAC layer is connected to the physical layer by the transport channel, and can 
be divided into a MAC-b sub-layer, a MAC-d sub-layer, a MAC-c/sh sub-layer, and a 
MAC-hs sub-layer according to the type of transport channel to be managed. The 
MAC-b sub-layer manages a BCH (Broadcast Channel), which is a transport channel 
handling the broadcasting of system information. The MAC-c/sh sub-layer manages a 
common transport channel, such as a forward access channel (FACH), a downlink 
shared channel (DSCH) or a paging channel (PCH), which is shared by a plurality of 
terminals. The MAC-d sub-layer manages a dedicated channel (DCH), which is a 
dedicated transport channel for a specific terminal. 

The RLC layer supports reliable data transmissions, and performs a segmentation 
and concatenation function on a plurality of RLC service data units (RLC SDUs) 
delivered from an upper layer. When the RLC layer receives the RLC SDUs from the 
upper layer, the RLC layer adjusts the size of each RLC SDU in an appropriate manner 
upon considering processing capacity, and then creates certain data units with header 
information added thereto. The created data units are called protocol data units 
(PDUs), which are then transferred to the MAC layer via a logical channel. The RLC 
layer includes a RLC buffer for storing the RLC SDUs and/or the RLC PDUs. 

A broadcast / multicast control (BMC) layer performs the functions of scheduling a 
cell broadcast (CB) message transferred from the core network 200 and of broadc 
asting the CB message to UEs located in a specific cell or cells. At the UTRAN 100, 
the CB message transferred from the upper layer is combined with information, such 
as a message ID, a serial number, a coding scheme, etc., and transferred to the RLC 
layer in the form of a BMC message and to the MAC layer through a common traffic 
channel (CTCH), which is a logical channel. The logical channel CTCH is mapped to a 
transport channel (i.e., a forward access channel (FACH)), and to a physical channel 
(i.e., a secondary common control physical channel (S-CCPCH). 

A packet data convergence protocol (PDCP) layer is located at an upper layer from 
the RLC layer, allowing data to be transmitted effectively via a radio interface with a 
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relatively small bandwidth through a network protocol, such as the IFV4 or the IV>. 
R>r this purpose, the PDCP layer performs the function of reducing unnecessary 
control information used in a wired network, and this function is called, header 
compression. Various types of header compression techniques, such as RFC2507 and 
RFC3095 (robust header compression: ROHC), which are defined by an Internet group 
called the IETF (Internet Engineering Task Ibrce), can be used. These methods allow 
transmission of only the absolutely necessary information required in the header part 
of a data, and thus transmitting a smaller amount of control information can redice the 
overall amount of data to be transmitted. 

[13] The radio resource control (RRC) layer located at the lowest portion of the third 

layer (L3) is only defined in the control plane, and controls the transport channels and 
the physical channels in relation to the establishing, the re-establishing, and the 
releasing of the radio bearers (RBs). Here, the RB signifies a service provided by the 
second layer (L2) for data transmission between the terminal 10 and the UTRAN 100. 
In general, the establishing of the RB refers to the setting of the characteristics of the 
radio protocol layers and channels for providing a particular service, and also refers to 
the procedures in setting the individual particular parameters and operation methods. 

[14] Among the RBs, the particular RB used between the UE and the UTRAN for 

exchanging RRC messages or NAS messages is called a SRB (Signaling Radio 
Bearer). When an SRB is established between a particular UE and the UTRAN, a RRC 
connection exists between the UE and the UTRAN. A UE having a RRC connection is 
said to be in RRC connected mode, and a UE without a RRC connection is said to be 
in idle mcde. When a UE is in RRC connected mode, the RNC determines the cell in 
which the UE is located (i.e., the RNC determines the UE location in units of cells), 
and manages that UE. Ibr a UE in RRC connected mode, signaling messages can be 
sent to the UTRAN. The UE having RRC connection remains in one state, among the 
states of CELL_DCH, CELL_PCH, URA_PCH, or CELLJFACH, according to the in- 
structions of the UTRAN. 

[15] In CELLJDCH state, the UE is allocated a dedicated physical channel, and uses a 

dedicated traffic channel and a dedicated control channel. In CELL_FACH state, the 
UE is allocated a dedicated control channel, and is additionally allocated a dedicated 
traffic channel. In CELL_PCH state and in URA_PCH state, the UE does not have a 
dedicated traffic channel or a dedicated logical channel established with the UTRAN. 
In CELL_FACH state and in CELL_DCH state, the UE can always send and receive 
messages with the UTRAN because a dedicated control channel exists. However, in 
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URA_PCH state or in CELL_PCH state, when the UE has a message that needs to be 
sent to the UTRAN, the UE changes to the CELL_FACH state upon performing a cell 
update procedure and then is able to exchange messages with the UTRAN. 

[16] Next, multimedia broadcast / multicast service (MB MS) will be described. MBMS 

refers to a downlink transmission service for providing data services such as, 
streaning services (e.g., multimedia, video on demand, webcast) or background 
services (e.g., e-mail, short message services (SMS), downloading), to a plurality of 
terminals by employing a downlink dedicated MBMS bearer service. At the UTRAN, 
for the MBMS bearer, a point-to-multipoint (p-t-m) radio bearer and a point-to-point 
(p-t-p) radio bearer services are used. 

[17] MBMS can be classified into a broadcast mode and a multicast mode. The MBMS 

broadcast mode refers to transmitting multimedia data to all users within a broadcast 
area, which is a region where broadcast service is possible. In contrast, MBMS 
multicast mode refers to transmitting multimedia data to only a certain specified user 
group within a multicast area, whereby a multicast area, which is a region where 
multicast service is possible. 

[18] Egure 3 shows a process in which a UMTS network provides a particular MBMS 

service (service 1) by using multicast mcde. Also, Egure 3 depicts an example when 
the UEs (UE1 and UE2) receive a particular service (service 1). Erst, the users (UE1 
and UE2) desiring to receive a MBMS service must perform a subscription procedure., 
Here, subscription refers to the acts of establishing a relationship between the service 
provider and the user. 

[19] Also, users (UEs) wishing to receive an MBMS service must also receive a service 

announcement provided from the network. Here, service announcement refers to the 
function of infonring the terminal about a list (index) of the services to be provided 
and related information. Also, if the user (UE) intends to receive a multicast mode 
MBMS service, the user (UE) should join a multicast subscription group. Here, 
f multicast group* refers to a group of users that receive a specific multicast service, and 
'joining' means merging with the multicast group that has particular users who wish to 
receive the specific multicast service. Using this joining procedure, the terminal can 
inform the UTRAN of its intent to receive the particular multicast data (multicast 
service). In contrast, for a terminal that has joined a particular multicast group, the 
procedure for terminating the joining of the multicast group is referred to as leaving 1 . 
The above-described subscribing, joining, and leaving procedures are performed for 
each terminal, and a terminal may perform the subscribing, joining, and leaving 
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procedures before, diring, or any time after data transirission. 

[20] While a particular MBMS service is in progress, one or more sessions for that 

service may occur in sequence. Here, a session may be defined in various ways. Ibr 
example, a session may be each complete episode of a multi-episode drama or a 
session may be certain portions of a sports program such as scenes that show goals in 
a soccer match. When data to be transmitted for a particular MBMS service is 
generated at the MBMS data source, the core network (CN) 130 informs a session start 
to the RNC 123. In contrast, when there is no further data at the MBMS data source to 
be transmitted for a particular MBMS service, the core network (CN) 1 30 informs a 
session stop to the RNC 123. Between the session start and the session stop, a data 
transfer procedure for the particular MBMS service can be performed. Here, only those 
terminals that have joined a multicast group for the MBMS service may receive data 
that is transmitted by the data transfer procedure. 

[21] In the above session start procedure, the UTRAN that received the session start 

from the core network (CN) transmits an MBMS notification to the terminals. Here, 
MBMS notification refers a function of the UTRAN for inforning a terminal that the 
transmission of data for a particular MBMS service within a certain cell is impending. 
The UTRAN can use the MBMS notification procedire to perform a counting 
operation that determines the number of terminals that wish to receive a particular 
MBMS service within a particular cell. The counting procedire is used to determine 
whether the radio bearer for providing the particular MBMS service should be set as 
point-to-multipoint (p-t-m) or point-to-point (p-t-p). Ibr selecting the MBMS radio 
bearer, the UTRAN internally establishes a threshold value. After perforning the 
counting function, the UTRAN may set a point-to-point MBMS radio bearer if the 
number of terminals existing within the corresponding cell is smaller than the 
threshold value, and may set a point-to-multipoint MBMS radio bearer if the number 
of terminals existing within the corresponding cell is greater than or equal to the 
threshold value. 

[22] If a point-to-point radio bearer is to be set, the UTRAN allocates a dedicated 

logical channel to each terminal (UE) and sends the data of the corresponding service. 
If a point-to-multipoint racfio bearer is to be set, the UTRAN uses a downlink common 
logical channel to send the data of the corresponding service. 
Disclosure of Invention 

Technical Problem 

[23] When the system provides a particular MBMS service to the tenrinals (UEs) by 
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establishing a point-to-point radio bearer, because the system is in one-to-one 
connection with each terrrinal, the system may (if necessary) receive feedback from 
each terrrinal, and use the information about which data blocks the terrrinal received 
and which data blocks the terminal cfid not receive, or the error rate of the data such 
that any necessary data blocks may be re-transnitted to the terminal. However, when a 
point-to^nultipoint radio bearer is established, a plurality of terminals use this radio 
bearer, thus the system cannot receive feedback of each terminal to re-transnit data or 
compensate for data errors according to the reception state of each terminal. Ac- 
cordingly, when the U IRAN uses a point-to-multipoint radio bearer to provide MBMS 
service, there will be certain terminals that could not receive data or that receive data 
with errors therein. When terminals do not completely receive proper data, service 
quality is severely degraded, thus causing problems in the conventional art. 

Technical Solution 

The present invention was developed in order to overcome the problems of the 
conventional art. The present invention provides a broadcast or multicast radio 
(wireless) system characterized in that for a radio (wireless) system transmitting a 
particular broadcast or multicast service to a plurality of terminals, and for the system 
to guarantee service quality to the terminal receiving the corresponding service, the 
UTRAN re-transmits the data of the corresponding service to the terminals after the 
session of the corresponding service is completed. 

Description of Drawings 

The features, nature, and advantages of the present invention will become more 
apparent from the detailed description set forth below when taken in conjunction with 
the drawings in which like reference characters identify correspondingly throughout 
and wherein: 

Hgure 1 depicts an exemplary basic structure of a UMTS network. 

Hgure 2 depicts a radio access interface protocol architecture between the terminal 
and UTRAN that is based upon the 3GPP wireless access network standards. 

Hgure 3 depicts a process in which a UMTS network provides a particular MBMS 
service (service 1) by using multicast mode to the UEs (UE1 and UE2). 

Hgure 4 depicts the operational procedures of a system constructed according to an 
embodiment of the present invention. 

Hgure 5 depicts a communications system structure induing a terminal (UE) and 
a network (UTRAN) according to an embodiment of the present invention. 

Mode for Invention 
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To achieve the technical solution by the present invention, while a session of a 
particular broadcast or multicast service is in progress, the UTRAN transmits to the 
terminals the data of the corresponding service transmitted from the CN, and at the 
same time, the data of the corresponding service is stored in its memory. When the 
session of the corresponding service ends, the UTRAN receives feedback regarding the 
corresponding service from the terminals and then determines the data that needs to be 
re-transmitted to the terminals, establishes a radio bearer to perform this re- 
transrrission, and transmits to the terminals the data determined as needing re- 
transmission. Here, it should be noted that the feedback information from the terminals 
is not absolutely required, as the system may determine the data for re-transnission 
without feedback from the terninals. 

The feedback information transmitted from a terminal to the system includes in- 
formation about the data that was not received by the terminal or that has errors 
generated therein. Namely, this feedback information refers to the information that is 
necessary in deteraining which data are to be re-transnitted. More specifically, the 
feedback information may be the sequence number of each PDU (Protocol Data Unit) 
or SDU (Service Data Unit), or the sequence number of a RTP (Real-time Transport 
Protocol) or RTCP (RTP Control Protocol). Alternatively, the feedback information 
may include the transmission time information or reproduction (reconstruction) time of 
the data that the terminal could not receive. 

In the above procedure, in order to prevent memory shortage that may occur when 
the UTRAN stores in its memory the data of each MBMS service, the data of the cor- 
responding service are not stored in its memory while an MBMS session is in progress, 
but the UTRAN can request and receive from the core network (CN) only the data 
determined to be re-transrritted after the session is completed and perform re- 
transmission to the terninals thereafter. 

In the above procedure, when the UTRAN re-transmits the data of the cor- 
responding service, a point-to-point radio bearer is established with each terminal that 
requested data re-transmission in order to transmit the data for the corresponding 
service requested by the terminal, or when there are many terminal that requested data 
re-transmissions, a point-to-multipoint radio bearer can be used to re-transmit the data 
of the corresponding service. 

In the above procedure, for the UTRAN to distinguish between one session of a 
corresponding MBMS service and a re-transmission of that session, the UTRAN can 
establish and send an identifier to the terninals to inform that re-transnission of a 
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session for the corresponding service is in progress, in addition to infonring the 
terminals about the information of the radio bearer for the corresponding service or the 
like. 

Also, in the above procedure, if the time needed for re-transmission is greater than 
the time period between the end of one session and the start of another session, the 
start of the next session may be affected by the re-transnission procedure of the 
previous session. To prevent this, the CN can additionally inform the UTRAN about 
the next session start time when sending a session stop message. Based upon this in- 
formation, the UTRAN can predict its time for performing its re-transnission 
procedure, and accordingly, the amount of cbta to be re-transnitted can be controlled 
or the data of the corresponding service is not re-transnitted. 

In order to guarantee service quality for a terminal for a particular MBMS service, 
the present invention provides a broadcast or multicast radio terminal (UE) system 
characterized in that after the corresponding session is complete, information regarding 
the data that the terminal did not properly receive is informed to the UTRAN, and then 
the corresponding data is received upon re-transnission from the UTRAN. 

To achieve this by the present invention, the terminal, while a session for an 
MBMS service is in progress or when a MBMS session is completed, forms the in- 
formation regarding the data it (fid not receive for the corresponding service. Also, 
when there are data that the terminal did not properly receive, the terminal provides in- 
formation regarding this to the UTRAN. Here, the terminal may send the cor- 
responding information by establishing a dedicated logical channel with the UTRAN, 
or the corresponding information may be informed to the UTRAN by using an uplink 
common channel. Here, the terminal may also inform the system of the amount of data 
that could not be received or the sequence numbers of the data not received. 
Thereafter, when the UTRAN begins re-transmission of data for the corresponding 
service, the terminal uses the radio bearer information provided from the UTRAN to 
establish a radio bearer, and beings to receive the corresponding data after the ratio 
bearer is established. 

Hgure 4 depicts the operational procedures of a system constructed according to an 
embedment of the present invention. 

In step 1, the CN sends a MBMS session start message to the UTRAN. 

In step 2, the UTRAN notifies the terminals that a session will start soon, and 
determines the type of radio bearer to be used by using a counting procedure. When 
the ratio bearer is determined, the UTRAN informs the terminals of the information 
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necessary to set the radio bearer. 

In step 3, the UTRAN receives data for the session of the corresponding service 
from the CN. This MBMS data is transiritted from the CN to the UTRAN until the 
session ends. 

In steps 4 and 5 the UTRAN stores the MBMS data received in step 3 in its 
memory, and simultaneously transmits this data to the terminal by using the radio 
bearer established in a corresponding cell. 

In step 6 as the terminal receives the corresponding service through the established 
radio bearer, and among the data of the corresponding service, collects information 
about those portions not received or received but containing errors. 

In steps 7 and 8, the session stop message from the CN arrives at the UTRAN. 
Also, the UTRAN informs the terminals that the session has stopped. Here, the session 
stop message transrritted from the CN may additionally include information regarding 
the start time of the next session. 

In step 9, The UTRAN determines whether a MBMS repairing session should be 
started. Here, the UTRAN may use the start time information of the next session 
included in the session stop message transmitted from the CN. If it is decided that the 
MBMS repairing session should be started, the UTRAN performs the subsequent 
procedures from step 10, and if not, the subsequent steps are not performed. Here, the 
MBMS repairing session refers to a session performed by the UTRAN for re- 
transmitting a portion of or all of the session data for the corresponding service to the 
terminal that did not properly receive the session data for the corresponding service, 
after a session for a particular MBMS service is completed. 

In step 10, the UTRAN informs the terminal that a MBMS repairing session will 
start soon. Here, the UTRAN may inform the terminals about the information that the 
terminals need to transmit when replying to the UTRAN or other information such as 
the conditions that the terminal must satisfy when repairing is requested. Additionally, 
the UTRAN can provide references used to determine which data was not received by 
the terninal by providing information about the corresponding session, for example, 
the total data amount of the corresponding session or the total reproduction 
(reconstruction) time of the data. 

In step 11, based upon the contents received in step 10, the terninal deternines 
whether a repairing session for the corresponding MBMS service is needed. Here, the 
terninal may use the amount of MBMS data it dd not receive or the number of 
MBMS data blocks it did not receive. Also, if the terninal determines that a MBMS 
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repairing session is needed, repairing reply information is generated as instructed by 
the UTRAN. If the terminal properly received all data for the corresponding service, 
the terninal need not send the repairing request message information to the UTRAN. 

[49] In step 12, the terninal sends the repairing reply information generated in step 1 1 

in the MBMS repairing request message to the UTRAN. 

[50] In step 13, the UTRAN deternines whether re-transirission should be performed 

and deternines the data to be re-transnitted based upon the information transmitted by 
the tenrinals in step 12. The data to be re-transnitted can be the data that could not be 
received by more than a set number of tenrinals, or the data corresponding to a certain 
time period of a corresponding service, or all of the data of the corresponding service, 
or the like. Here, the UTRAN may refrain from starting the MBMS repairing session 
based upon the next session start time and the replay information of the terninal 
informed by the CN, or the amount of data to be re-transnitted can be appropriately re- 
adjusted according to the time remaining until the next session start time. Also, if the 
number of tenrinals requesting MBMS repairing is less than a certain reference value, 
the UTRAN uses a point-to-point radio bearer or uses a point-to-multipoint ratio 
bearer if greater than or equal to the reference value, to re-transmit the MBMS data. If 
a point-to-point radio bearer is used, the UTRAN establishes a point-to-point radio 
bearer with each of the tenrinals and re-transnits MBMS data according to the reply 
information of each terninal. Also, if a point-to-multipoint radio bearer is used, the 
UTRAN performs the procedures of step 14. 

[51] In step 14, if the point-to-multipoint radio bearer is to be used, the UTRAN 

informs the terninal that the MBMS repairing session will soon start, and informs the 
parameters to be used for establishing the radio bearer. Also, the UTRAN, based upon 
the contents determined in step 13, establishes the radio bearer, informs the tenrinals 
about the establishment information of the conesponding radio bearer, and begins re- 
transirission of data for the conesponding service. Here, it should be noted that a 
MBMS session start notification message can be used instead of the MBMS repairing 
session start notification message. In this case, a repairing session indicator is ad- 
ditionally established to inform the tenrinals that the conesponding session is a 
session for performing repairing, in order to prevent unnecessary repeated reception of 
the conesponding session by a terninal that has properly received all data without any 
enors. 

[52] In step 15, among the data stored in its memory, the UTRAN transirits the data to 

be re-transnitted using the radio bearer established in the previous step, and the 
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terminals that had requested repairing receives the transmitted data. Here, if the data of 
a corresponding session has not been stored die to the lack of memory in the UTRAN, 
then the UTRAN may request the data to be re-transmitted to the CN and receive the 
same therefrom. 

[53] In the conventional art, if MBMS service is provided by using a point- 

to-multipoint radio bearer, there is no way for the terminal to correct the situation 
where portions of data are not received die to poor channel conditions or if errors are 
generated in the received data. By having the UTRAN re-transirit the data that the 
terminal dd not receive for a corresponding service, the present invention can 
guarantee the quality of the correspondng service. 

[54] The present invention can employ a variety of software, hardware, and/or a 

combination thereof to achieve the above-identified procedures and steps. K>r 
example, Hgure 5 depicts a communication system comprising a terminal (UE 510) in 
radio communication with a network (UTRAN 520 and CN 530) accordng to an 
embedment of the present invention. The network (UTRAN 520 and CN 530) may 
include various hardware and software components. Tor example, the UTRAN 520 
comprises an RNC (526), being connected to a plurality of Node Bs (522), and having 
a processor (526-1) and a memory (526-2). An RNC (528), being connected to a 
plurality of Node Bs (524), may also comprise a processor (528-1) and a memory 
(528-2). The RNCs (52$ 528) are connected with one another via an interface, and 
connected with the CN (530) via another interface. The network (UTRAN 520 and CN 
530) handles the various signal processing procedures for communication with the 
terminal (UE 510) as described previously. Here, it should be noted that various 
software codes and protocols that are required for achieving the present invention may 
be stored in one or more memory devices and executed by one or more processors 
located within the Node Bs (822, 824), the RNCs (82^ 828), and/or other network 
elements. 

[55] The present invention provides a method of receiving a point-to-multipoint service 

in a mobile tenrinal using data error correction, the method comprising: receiving data 
blocks of a point-to-multipoint service during a session; transmitting a repairing 
request to a network in a point-to-point manner, the repairing request induing in- 
formation of at least one data block that was unsuccessfully received during the 
session; and receiving the at least one data block from the network after a session stop, 
such that the unsuccessfully received data blocks are successfully received. 

[56] The present invention also provides a method of providng a point-to-multipoint 
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service from a communications network using data error correction, the method 
comprising: transmitting data blocks of a point-to-multipoint service diring a session; 
receiving a repairing request from a terminal in a point-to-point manner, the repairing 
request inducing information of at least one data block that was unsuccessfully 
received during the session; and transmitting the at least one data block to the terminal 
after a session stop, such that the unsuccessfully received data blocks are successfully 
received by the terminal. 

[57] Additionally, the present invention provides a mobile terminal for receiving a 

point-to-multipoint service using data error correction, the terminal comprising: an 
antenna; a memory having software codes stored therein; and a processor connected 
with the antenna and the memory, the processor executing the software codes for, 
receiving, via the antenna, data blocks of a point-to-multipoint service diring a 
session; transmitting, via the antenna, a repairing request to a network in a point- 
to-point manner, the repairing request including information of at least one data block 
that was unsuccessfully received diring the session; and receiving, via the antenna, the 
at least one data block from the network after a session stop, such that the unsuc- 
cessfully received data blocks are successfully received. 

[58] Furthermore, the present invention provides a communications network for 

providing a point-to-multipoint service using data error correction, the network 
comprising: a memory having software codes stored therein; and a processor 
connected with the memory, the processor executing the software codes for, 
transnitting data blocks of a point-to-multipoint service during a session; receiving a 
repairing request from a terminal in a point-to-point manner, the repairing request 
inducing information of at least one data block that was unsuccessfully received 
during the session; and transnitting the at least one data block to the terminal after a 
session stop, such that the unsuccessfully received data blocks are successfully 
received by the terminal. 

[59] Preferably, the network can comprise a core network or a U I RAN. Here, the 

UTRAN can store point-to-multipoint service data sent from a core network, and can 
select the repairing data from the stored point-to-multipoint service data. Also, the 
UTRAN can request the repairing data from a core network without storing point- 
to-multipoint service data in the UTRAN. 

[60] R>r the method of data error correction for the terminal, the method of (fata error 

correction for the network, the terminal, and the network described above, the 
following aditional features are preferred. Preferably, a session can be defined as a 
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time period during which particular data is sent by the network. Also, the step of 
receiving data blocks of the point-to-multipoint service can be performed in a point- 
to-multipoint manner, and the step of receiving data locks of the point-to-multipoint 
service can be performed in a point-to-point manner. Additionally, the information can 
be a sequence number for a packet, while a packet can be a protocol data unit, a 
service data unit, a real-time transport protocol packet or a RTP control protocol 
packet. Preferably, the information can be associated with a data transmission time or a 
data play time, or the information can e associated with an amount of the at least one 
data block that was unsuccessfully received. The information can be generated while 
the session is in progress or after the session is completed. Preferably, the transmitting 
step can be performed via a dedicated logical channel or an uplink common channel. 

[61] Although various aspects, embodiments, and features of the present invention have 

been described for a UMTS communications scheme, many of these techniques can be 
advantageously applied for other communications methods and systems. 

[f2] The foregoing description of the preferred embodiments is provided to enable any 

person skilled in the art to make or use the present invention. Various modifications to 
these embodiments will be readily apparent to those skilled in the art, and the generic 
principles defined herein may be applied to other embodiments without the use of the 
inventive faculty. Thus, the present invention is not intended to be United to the em- 
bodiments shown herein but us to be accorded the widest scope consistent with the 
principles and novel features disclosed herein. 
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Claims 

[I] A method of receiving a point-to-multipoint service in a mobile tenrinal using 
data error correction, the method comprising: 

receiving data blocks of a point-to-multipoint service during a session; 
transmitting a repairing request to a network in a point-to-point manner, the 
repairing request including information of at least one (fata block that was unsuc- 
cessfully received (faring the session; and 

receiving the at least one data block from the network after a session stop, such 
that each of the unsuccessfully received data blocks is successfully received. 

[2] The method of claim 1 , wherein a session is a time period (faring which 

particular data is sent by the network. 

[3] The method of claim 1, wherein the step of receiving data blocks of the point- 

to-multipoint service is performed in a point-to-multipoint manner. 

[4] The method of claim 1, wherein the step of receiving data locks of the point- 

to-multipoint service is performed in a point-to-point manner. 

[5] The method of claim 1, wherein the information is a sequence number for a 

packet. 

[6] The method of claim 5> wherein a packet is a protocol (fata unit, a service data 

unit, a real-time transport protocol packet or a RTP control protocol packet. 
[7] The method of claim 1, wherein the information is associated with a data 

transmission time or a data play time. 
[8] The method of claim 1, wherein the information is associated with an amount of 

the at least one data lock that was unsuccessfully received. 
[9] The method of claim 1, wherein the information is generated while the session is 

in progress or after the session is completed. 
[10] The method of claim 1, wherein the transmitting step is performed via a 

dedicated logical channel or an uplink common channel. 

[II] A method of providing a point-to-multipoint service from a communications 
network using data error correction, the method comprising: 
transnitting data blocks of a point-to-miltipoint service during a session; 
receiving a repairing request from a tenrinal in a point-to-point manner, the 
repairing request inducing information of at least one data block that was unsuc- 
cessfully received during the session; and 

transmitting the at least one data block to the terminal after a session stop, such 
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that each of the unsuccessfully received data blocks is successfully received by 
the terminal. 

[12] The method of claim 11, wherein a session is a time period during which 

particular data is sent by the network. 
[13] The method of claim 11, wherein the step of transmitting data blocks of the 

point-to-nultipoint service is performed in a point-to-multipoint manner. 
[14] The method of claim 1 1, wherein the step of transmitting (fata blocks of the 

point-to-rmltipoint service is performed in a point-to-point manner. 
[15] The method of claim 1 1, wherein the information is a sequence number for a 

packet. 

[16] The method of claim 15 wherein a packet is a protocol data unit, a service data 

unit, a real-time transport protocol packet or a RTP control protocol packet. 
[17] The method of claim 1 1, wherein the information is associated with a data 

transmission time or a data play time. 
[18] The method of claim 11, wherein the information is associated with an amount 

of the at least one (fata block that was unsuccessfully received. 
[19] The method of claim 11, wherein the information is generated by the terminal 

while the session is in progress or after the session is completed. 
[20] The method of claim 11, wherein the receiving step is performed via a dedicated 

logical channel or an uplink common channel. 
[21] A mobile terminal for receiving a point-to-multipoint service using data error 

correction, the terminal comprising: 

an antenna; 

a memory having software codes stored therein; and 

a processor connected with the antenna and the memory, the processor executing 
the software codes for, 

receiving, via the antenna, data blocks of a point-to-multipoint service (faring a 
session; 

transmitting, via the antenna, a repairing request to a network in a point-to-point 
manner, the repairing request including information of at least one data block 
that was unsuccessfully received daring the session; and 
receiving, via the antenna, the at least one data block from the network after a 
session stop, such that each of the unsuccessfully received data blocks is suc- 
cessfully received. 

[22] The terminal of claim 21 , wherein a session is a time period during which 
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particular data is sent by the network. 

The terminal of claim 21, wherein the processor performs the step of receiving 
data blocks of the point-to-multipoint service in a point-to-multipoint manner. 
The terminal of claim 21, wherein the processor performs the step of receiving 
data blocks of the point-to-multipoint service in a point-to-point manner. 
The tenrinal of claim 21, wherein the information is a sequence number for a 
packet. 

The tenrinal of claim 2$ wherein a packet is a protocol data unit, a service data 
unit, a real-time transport protocol packet or a RTP control protocol packet. 
The tenrinal of claim 21, wherein the information is associated with a data 
transmission time or a data play time. 

The tenrinal of claim 21, wherein the information is associated with an amount 
of the at least one data block that was unsuccessfully received. 
The tenrinal of claim 21, wherein the information is generated while the session 
is in progress or after the session is completed. 

The tenrinal of claim 21, wherein the processor performs the transmitting step 

via a dedicated logical channel or an uplink common channel. 

A communications network for providing a point-to-niiltipoint service using 

data error correction, the network comprising: 

a memory having software codes stored therein; and 

a processor connected with the memory, the processor executing the software 
codes for, 

transmitting data blocks of a point-to-imltipoint service during a session; 
receiving a repairing request from a tenrinal in a point-to-point manner, the 
repairing request induing information of at least one data block that was unsuc- 
cessfully received during the session; and 

transmitting the at least one data block to the terminal after a session stop, such 
that each of the unsuccessfully received (fata blocks is successfully received by 
the tenrinal. 

The network of claim 31, wherein a session is a time period diring which 
particular data is sent by the network. 

The network of claim 31, wherein the processor performs the step of transiritting 
data blocks of the point-to-multipoint service in a point-to-multipoint manner. 
The network of claim 31, wherein the processor performs the step of transmitting 
data blocks of the point-to-multipoint service in a point-to-point manner. 
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[35] The network of claim 3 1 , wherein the information is a sequence number for a 

packet. 

[36] The network of claim 35, wherein a packet is a protocol data unit, a service data 

unit, a real-time transport protocol packet or a RTP control protocol packet. 
[37] The network of claim 31, wherein the information is associated with a data 

transmssion time or a data play time. 
[38] The network of claim 31, wherein the information is associated with an amount 

of the at least one data block that was unsuccessfully received. 
[39] The network of claim 31, wherein the information is generated by the terminal 

while the session is in progress or after the session is completed. 
[40] The network of claim 3 1 , wherein the processor performs the receiving step via a 

dedicated logical channel or an uplink common channel. 
[41] The network of claim 3 1 , wherein the network comprises a core network. 

[42] The network of claim 3 1 , wherein the network comprises a UTRAN. 

[43] The network of claim 42, wherein the UTRAN stores point-to-multipoint service 

data sent from a core network, and selects the repairing data from the stored 

point-to-railtipoint service data. 
[44] The network of claim 42, wherein the UTRAN requests the repairing data from a 

core network without storing point-to-multipoint service data in the UTRAN. 
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